The result from Requirements Engineering is a Requirements Specification. Characteristics of a good Requirements Specification are unambiguity, completeness, verifiability, consistency, modifiability, traceability, correctness and ranked for importance and/or stability.This work defines these quality attributes and answers the questions how to reach these attributes and the diffuculties which exist in this area.This work should be read to get an overwiew of the area Requirements Engineering and Requirements Specification..

Requirements Engineering is a widespread topic in the research field of informatics. However, there is little research regarding lack of requirements documentation and how it is perceived. The same applies for how Requirements Engineering in retrospect can be implemented. This is a debated issue on blogs and forums but it has not been reflected in the research area.Therefore, this study concerns research questions regarding how the developers, testers and requirements analyst experience the lack of requirements documentation and how Requirements Engineering in retrospect can be implemented.To answer these questions, data collection has been conducted through qualitative interviews with individuals affected by this problem in their everyday work.This study has provided an explanation of how the problem is perceived and what the consequences are, both direct and indirect. The impacts are divided into three categories and are presented as, emotional consequences, system implications and consequences regarding re source consumption.

Requirements Engineering is a widespread topic in the research field of informatics. However, there is little research regarding lack of requirements documentation and how it is perceived. The same applies for how Requirements Engineering in retrospect can be implemented. This is a debated issue on blogs and forums but it has not been reflected in the research area.Therefore, this study concerns research questions regarding how the developers, testers and requirements analyst experience the lack of requirements documentation and how Requirements Engineering in retrospect can be implemented.To answer these questions, data collection has been conducted through qualitative interviews with individuals affected by this problem in their everyday work.This study has provided an explanation of how the problem is perceived and what the consequences are, both direct and indirect. The impacts are divided into three categories and are presented as, emotional consequences, system implications and consequences regarding re source consumption.

Requirements Engineering is a widespread topic in the research field of informatics. However, there is little research regarding lack of requirements documentation and how it is perceived. The same applies for how Requirements Engineering in retrospect can be implemented. This is a debated issue on blogs and forums but it has not been reflected in the research area.Therefore, this study concerns research questions regarding how the developers, testers and requirements analyst experience the lack of requirements documentation and how Requirements Engineering in retrospect can be implemented.To answer these questions, data collection has been conducted through qualitative interviews with individuals affected by this problem in their everyday work.This study has provided an explanation of how the problem is perceived and what the consequences are, both direct and indirect. The impacts are divided into three categories and are presented as, emotional consequences, system implications and consequences regarding re source consumption.

Requirements Engineering is a widespread topic in the research field of informatics. However, there is little research regarding lack of requirements documentation and how it is perceived. The same applies for how Requirements Engineering in retrospect can be implemented. This is a debated issue on blogs and forums but it has not been reflected in the research area.Therefore, this study concerns research questions regarding how the developers, testers and requirements analyst experience the lack of requirements documentation and how Requirements Engineering in retrospect can be implemented.To answer these questions, data collection has been conducted through qualitative interviews with individuals affected by this problem in their everyday work.This study has provided an explanation of how the problem is perceived and what the consequences are, both direct and indirect. The impacts are divided into three categories and are presented as, emotional consequences, system implications and consequences regarding re source consumption.

Abstract The purpose of writing this thesis was to improve methods during requirements engineering phase. Usercentred system engineering has some problem areas, which are examined and verified to create a new guideline for developers. This guideline tends to make Requirements Engineering more effective and help developers create more concrete requirements. It is not uncommon that system development projects ends up with unsatisfied users or delay in deliveries. The reasons are different kinds of communication problems between users and developers during verification of requirements. There is a therapy model, called solution-focused therapy, used in family and individual therapy. The model focuses on solutions for the future instead of problems in the past.

Abstract The purpose of writing this thesis was to improve methods during Requirements Engineering phase. Usercentred system engineering has some problem areas, which are examined and verified to create a new guideline for developers. This guideline tends to make Requirements Engineering more effective and help developers create more concrete requirements. It is not uncommon that system development projects ends up with unsatisfied users or delay in deliveries. The reasons are different kinds of communication problems between users and developers during verification of requirements.

Denna rapport behandlar den marknadsinriktade Requirements Engineering (RE) processen. Allt fler företag väljer idag att implementera standardsystem i sina verksamheter. Den situation som ett standardsystem utvecklas i är annorlunda jämfört med den som ett kundspecifikt system utvecklas i. Detta innebär att den traditionella RE-processen inte är anpassad till dessa nya förhållanden.Syftet med denna rapport är därför att utreda vad som kännetecknar en marknadsinriktad RE-process som stödjer kravhanteringsarbetet vid utvecklingen av ett standardsystem. Rapporten avser även att undersöka hur RE tillämpas av marknadsinriktade systemtillverkare i praktiken.

Ett branschanpassat affärssystem är avsett för organisationer verksamma inom samma bransch. Syftet med denna typ av affärssystem är att ge högre passform än standardiserade affärssystem och vara billigare än skräddarsydda affärssystem. Det råder dock brist på kunskap om hur dessa ska utvecklas. Genom vår litteraturstudie presenteras en kravinsamlingsmodell med utgångspunkt i Requirements Engineering som ska ge stöd för utvecklare vid insamling av krav för branschanpassade affärssystem. Utöver det identifierades ett flertal aktiviteter relaterade till modellen.

Detta examensarbete innehåller en introduktion till informationssystemutveckling och Requirements Engineering (RE). Vikten av att utföra RE på ett effektivt sätt är stor. Hela informationssystemet blir lidande om denna del inte utförs på ett tillfredställande sätt. För att utföra RE finns en rad tekniker och verktyg. Detta arbete behandlar en teknik i RE, nämligen Use Case-modellering.

Ett effektivt användande av ett informationssystem förbättrar informationshanteringen inom en verksamhet. För att ett informationssystem ska kunna fungera effektivt krävs att det motsvarar de krav som ställts på informationssystemet av olika intressenter.Requirements Engineering (RE) är en viktig del av systemutvecklingsprocessen för att kunna säkerställa en väl fungerande kravhantering. Use case är en teknik som kan användas som hjälpmedel i RE-processen för att identifiera och dokumentera krav.Syftet med detta examensarbete är att undersöka om use case är tillräcklig som enda teknik för att identifiera och dokumentera krav samt vilka eventuella kompletterande tekniker som används bland systemutvecklare. Resultatet av undersökningen visar att use case-tekniken inte är tillräcklig utan måste kompletteras med andra tekniker för att möjliggöra att samtliga krav kan identifieras och dokumenteras..

According to statistics, requirements management is identified as a major source of error to failed IT-projects. Moreover communication is identified as a factor affecting the require-ments management and can lead to deficiencies in the requirements. The requirements analyst is responsible for managing the requirements from the different stakeholders, act as a com-munication accommodator and to translate abstract requirements expressed by users to more specific requirements that developers can implement. The purpose of this thesis is to study the role of the requirements analyst to investigate the problems that may arise in working with requirements management.  To achieve the purpose we have performed a requirements management process in which we ourselves took the role as the requirements analysts. The requirements management process consisted of three phases: gather requirements, document requirements and validate require-ments.

This thesis has been carried out in collaboration with the IT Company MPQ consulting AB in Halmstad. The task we were assigned by MPQ concerned the development of a scooter that can be used year round. We have with the companydeveloped the criteria and requirements for the product in which the goal is toproduce a primary solution that meets the set criteria and fall within the project'sboundaries.The project involves a wide range of different design methods for idea generationand idea development. The project also addresses engineering methods such asprinciple and primary engineering. Occurringmethods in the project include FredyOlsson principle and primary engineering in cooperation with SVID's - Swedishindustrial design process, etc.The final solution will be presented in the form of sketches, CAD models withassociated drawings and a rendering from the program Keyshot..

Requirements Engineering processen, RE-processen, är den tidiga fasen i ett systemutvecklingsprojekt, där RE-processens syfte är att identifiera, verifiera, validera samt dokumentera en mängd krav som ett nytt eller utvidgat system skall konstrueras efter. RE-processen skall mynna ut i en kravspecifikation där de dokumenterade kraven finns samlade.Detta examensarbete behandlar ämnet systemutveckling och fokuserar på konsultföretags metodanvändande under RE-processen. Att fokus ligger på RE-processen beror på att denna fas är den mest kritiska delen i ett systemutvecklingsprojekt.För att få svar på vilka metoder som konsultföretag använder under RE-processen har en intervjundersökning gjorts.Resultatet av undersökningen visar att konsultföretag använder olika metoder under RE-processen. Sättet att använda dem fungerar på ungefär samma sätt med ett aktivt deltagande från kundernas sida. Systemutvecklingsmetoderna är också uppbyggda på liknande sätt med samma synsätt att arbeta efter..

This report is a degree paper made for the Engineering program in Technical Chemistry at the School of Engineering, Jönköping University.The intention of the project which is described, is to answer whether HV71 might become environmentally certified according to the criteria of "miljödiplomering". The project also included an investigation of which further steps and measures must be undertaken by the enterprise in order to achieve the certificate. The final part was to implement the necessary requirements for the certification.The report starts with a short background where the origin and function of environmental management is briefly explained.The report continues with how the practical work with the environmental certification was done according to requirements of Jönköping municipality. Motivations behind each part of the process are given as well as explanations of how each part of the process was carried out.The final result of the project was that HV71 took the measures needed to live up to the required demands. After a revision made by Miljöstrategen i Jönköping AB, HV71 passed the demands and became thereby an environmentally certified business..